Columbia Kermit/kermit.zip/newsgroups/misc.19941031-19941221/[e-mail]_Thu Dec 1 17:13:29 1994.msg

Internet Message Format | 2020-01-01 | 4KB

Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA25005
  (5.65c+CU/IDA-1.4.4/HLK for <[e-mail]>); Thu, 1 Dec 1994 16:47:19 -0500
Received: by apakabar.cc.columbia.edu id AA22606
  (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Thu, 1 Dec 1994 16:47:10 -0500
Path: news.columbia.edu!sol.ctr.columbia.edu!math.ohio-state.edu!uwm.edu!news.alpha.net!news.mathworks.com!uhog.mit.edu!bloom-beacon.mit.edu!gatech!newsxfer.itd.umich.edu!caen!news.tc.cornell.edu!travelers.mail.cornell.edu!newstand.syr.edu!cockpit.syr.edu!vefatica
From: [e-mail] (Vincent Fatica)
Newsgroups: comp.protocols.kermit.misc
Subject: Fast file transfer
Date: 1 Dec 1994 17:13:29 GMT
Organization: none
Lines: 59
Message-Id: <3bl07p$[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: sudial-147.syr.edu
Apparently-To: [e-mail]

Those who are really serious about getting the very fastest file transfer
should have some standard by which to measure their own Kermit's performance
and compare it to others. By this I mean an utterly uncompressible file
of significant length. It's easy to make one: using your favorite language,
write characters in the range 0 to 255 AT RANDOM to a file. When you're
done, try zip or gzip on it ... it'll get bigger ... it's really
uncompressible. I keep a 100,000 byte such file (called "tight") around
for testing purposes.

I routinely achieve 1635 cps on a 14400 dialed connection and 1090 cps on
a 9600 dialed connection. I believe this is pretty darned close to optimum
for uncompressible data. How do you do it?

As has been said, long packets and sliding windows do a great deal in
speeding up file transfer, but you won't approach the speeds above with
long packets and sliding windows alone; the key to squeezing out that last
20-25% of speed is CONTROL CHARACTER UNPREFIXING.

By default, Kermit "prefixes" (adds a byte to) a fairly large number of
characters; this is so intervening hardware and software won't misinterpret
them and do something undesirable. For example, if there is xon/xoff flow-
control in effect (anywhere along the way), an unprefixed ^S will be
interpreted as a "stop" (probably not as desired). In addition, the
characters which Kermit prefixes are among those which appear frequently
in compressed data. So by default, Kermit does it as safely as possible.

But in any given situation there's probably only a few characters which need
to be prefixed; so in general you want to tell the sending Kermit to:

    set control unprefixed all
    set control prefixed [only the necessary ones]

As Frank da Cruz has pointed out, precisely which ones are necessary is very
much connection-dependent, and so experimentation is the only way to find
out what you need. On a dialed connection where there's no xon/xoff
(anywhere) and where I know the dial-up server is in transparent mode, I
need only "set control prefixed 0 1 3". If there were xon/xoff in effect,
I'd add to the list 17 19 145 147 (^Q, ^S, and their 8-bit counterparts).
When I use Kermit to make a network connection, I add 13 141 255.
So ... experiment.

Upon first connecting to my dial-up server (a Cisco, I think) I have the
opportunity to issue commands (only a few) to it. I can say, for example,
"terminal download" which puts it in transparent mode, or
"terminal flow hardware in out" which I imagine does just what it says.
I don't pretend to be knowledgeable about such server issues, so if anyone
would care to elaborate, I would appreciate it.

Also by default, Kermit tries to do a little compressing of it's own by
simply replacing strings of repeated characters with something shorter.
This is probably futile for data that's already compressed. Even though
it's not clear that Kermit's actually wasting time trying to do this, I tell
the sending Kermit to "set repeat count off" whenever I know the data is
already compressed.

Respectfully,

Vincent Fatica